fix: accept numpy integer types as Parachute trigger - #1116

I exercised the trigger-type boundary on head e3d2f0fe7c583f3a632d9643dca98b071c60b79f:

Using numbers.Real with the explicit bool guard gives the intended boundary. A raw NUMERICAL_TYPES check would also include complex values, and Python bool needs its own exclusion, so I would keep the current predicate even though the shared constant was suggested earlier.

Two changes still look necessary before review:

1. The pull request targets master; the development guide says ordinary fixes should target develop.
2. The patch has no tests. A parametrized constructor test covering the eight cases above would protect both the NumPy-integer fix and the bool/complex exclusions.

No branch changes were made. Environment: Python 3.12.6; NumPy 2.5.2; RocketPy PR head above; macOS 26.5.2 arm64.

I understand this PR still needs some fixes.

1. Adding unit tests
2. Using the NUMERICAL_TYPES from the Function module

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.37%. Comparing base (e0ff281) to head (e3d2f0f).
⚠️ Report is 58 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #1116      +/-   ##
===========================================
+ Coverage    82.18%   82.37%   +0.19%     
===========================================
  Files          122      122              
  Lines        16355    16378      +23     
===========================================
+ Hits         13441    13492      +51     
+ Misses        2914     2886      -28     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Thanks for the boundary table — that settles the NUMERICAL_TYPES question, and you are right to keep your predicate. I checked the constant:

NUMERICAL_TYPES = (float, int, complex, np.integer, np.floating, np.complexfloating)

so it would accept complex / np.complex64, and because bool subclasses int it would not reject True either. numbers.Real plus the explicit bool guard is the correct boundary here. Dropping that request — please ignore item 2 of my earlier comment.

What is still missing is item 1, the tests. The diff is still only the one-line predicate change in parachute.py. Please add unit tests (tests/unit/rocket/test_parachute.py or tests/unit/test_parachute_triggers.py) that pin exactly the table you posted:

• int and np.int64 accepted as an altitude trigger
• float and np.float32 accepted
• bool and np.bool_ rejected with ValueError
• complex and np.complex64 rejected with ValueError

That way the boundary you measured by hand is the boundary CI enforces from now on. With those in, this is good to go.

One note: the workflow runs on this PR had been sitting in action_required and never actually executed, so the green/absent checks were not meaningful. I approved them, so you should get real results now.